Настольная книга тимлида разработки ПО - Виктор Большаков

Основная выгод от автоматизации процессов разработки:

— Снижение затрат на разработку

— Уменьшение времени выполнения задач

— Улучшение качества разработки

— Повышение прозрачности и управляемости процесса разработки

— Уменьшение зависимости от сотрудников

К автоматизации процессов разработки относятся:

— Средства автоматизированного планирования и контроля задач

— Статический анализ кода

— Генераторы кода

— Автоматизированное тестирование

— Средства автоматизации деплоя

— Скрипты диагностики

— Скрипты резервного копирования и восстановления резервных копий

— Средства управления инфраструктурой

Для автоматизации процессов разработки применяются инструменты, выбор которых описан выше.

Не рекомендуется автоматизировать процессы, если они еще не эксплуатировались или находятся в состоянии отладки. Это значит, что новый процесс, который еще может измениться, лучше несколько циклов выполнять вручную, пока не зафиксируется его стабильная версия.

Любой продукт — это автоматизация бизнес-процессов. Каждый бизнес-процесс преследуют определенную цель, а их набор в продукте создает определенную ценность для бизнеса. То есть продукт (информационная система) имеет конкретную ценность и целью его (продукта) создания является получение этой ценности.

Жизненные стадии продукта это:

— исследование;

— планирование;

— проектирование;

— изготовление;

— тестирование;

— публикация.

При этом стадии не пересекаются в рамках одной версии продукта:

Продукт может быть:

— Описан

— Спроектирован

— Разработан

— Эксплуатируется

— Архивирован

Стратегия создания продукта может отталкиваться от Гибких границ проекта или от Фиксированных границ проекта. При этом под границами понимаются Стоимость, Требования к продукту, Срок и Качество.

Стратегия развития и дорожная карта должны вести преобразование продукта к определенной цели, которая будет уточняться со временем.

Функциональные требования к продукту: являются частью описания бизнес-процессов или раскрывают подробности выполнения различных бизнес-процессов. Например, классический интернет-магазин автоматизирует бизнес-процесс коммуникации организации с покупателем, при этом:

— Каталог — выполняет роль справочника по товарам и ценам, некий прайс-лист с картинками. Он трансформировался из бумажного формата в электронный, и хотя способ передачи информации изменился, цель процесса осталась прежней.

— Корзина и оформление покупки — автоматизируют формирование и прием заказа от покупателей. Раньше заказы принимали по телефону или с помощью почтовых отправлений. Карточки заказов шли в бумажных каталогах на последних страницах, чтобы можно было отправить письмом несколько заказов.

— Контакты, О компании… — информирование покупателей об условиях сделки, продавце и т. д.

Процессы могут иметь разные формы при одной и той же цели.

Большая часть бизнес-подразделений недостаточно зрелая для того, чтобы сразу выдавать описанные бизнес-процессы, поддержание которых стоит достаточно дорого для компании.

Продукты могут автоматизировать деятельность клиентов или взаимоотношения с клиентами. При таком раскладе функции продукта проверяются бизнес-гипотезами. Эффективность бизнес-гипотез необходимо подтверждать увеличением вовлеченности, уровнем продаж и др. Другой случай — продукты, которые автоматизируют внутреннюю деятельность предприятий. Они как раз не нуждаются в доказательстве эффективности тех или иных своих функций. Их деятельность уже осуществляется в неавтоматизированном виде, что делает обратную связь от внедрения достаточно быстрой.

Тимлид, как любой другой разработчик, может и должен подсказывать владельцу продукта наиболее оптимальные пути развития. Также в его полномочия входит извлечение данных знаний из всей команды. Это позволит использовать полезные UI элементы и улучшить UX.

В главе «Качество постановки задач» рассматривались различные методы формализации задач. Выбор метода должен быть основан на необходимости более точной (качественной) реализации задач и ориентированы на описание функций продукта.

В некоторых компаниях существуют отдельные аналитики (системные аналитики или бизнес-аналитики), занимающиеся описанием бизнес-процессов или функционала продукта. Бизнес-аналитики фокусируются на проектировании, оптимизации и документировании бизнес-процессов, ролях, должностных инструкциях. Системные аналитики проектируют интерфейсы и их на основании описанных бизнес-процессов. Достаточно часто бизнес-аналитики занимаются системным анализом и наоборот — системные аналитики занимаются бизнес-анализом. Иногда этих специалистов привлекают к оценке бизнес гипотез.

В случае, если в компании нет выделенной роли бизнес-аналитика или системного аналитика, эту функцию может выполнять владелец продукта, тимлид, заказчик и др. Если эту роль выполняете вы сами (тимлид), то вам необходимо придерживаться следующих принципов:

— Постоянно держите в фокусе основную цель продукта и основной бизнес-процесс зарабатывания денег.

— Определите охват продукта и его пользователей.

— Функции продукта должны отвечать потребностям пользователей, а также помогать им более эффективно и качественно выполнять свою роль в бизнес-процессе.

— Проектирование их должно обеспечивать удобство и простоту пользования без чтения документации.

— Система понятно и предсказуемо реагирует на действия пользователей.

— Приятное эстетическое ощущение от интерфейса продукта.

— Обработка ошибок системы, дающая понимание того, что произошло и не требующая от пользователей дополнительных действий.

Тимлид может нести полную ответственность за архитектуру продукта, а может быть подчинен решениям отдельного архитектора. Процесс работы над архитектурой продукта бывает сложным. Он представляет собой совещательный орган, принимающий решения по определенным критериям в необходимых случаях.

Архитектуру информационной системы можно представить в виде слоев:

— Технологический

— Инфраструктура

— Платформа

— Информационный

— Приложение

— Данные

— Бизнес

— Сервисы

— Процессы

— Компетенции

— Ценности

Архитектура — это набор принятых и реализованных решений в отношении элементов (каждого слоя) и их взаимодействия.

Этап первичного проектирования архитектуры часто сопровождается созданием документации — диаграмм и схем. Для этих целей используются UML диаграммы, эта нотация практически не имеет достойной альтернативы на текущий момент.

Проектирование приложения сводится к вопросам:

— Как систематизировать и логически разделить программный код (функциональный, по типу объектов, по слоям объектов, по фичам)

— Уровень отделения логических блоков (монолит, сервисная архитектура)

— Платформа (serverless, на одном сервере, на разных физических серверах, в контейнерах, на виртуальных машинах)

Основными критериями при выборе программного языка, фреймворка и инфраструктуры будут:

— Наличие компетенции в технологии

— Способность технологии решить поставленную задачу

— Эффективность решения данной задачи на заданной технологии (стоимость, скорость, расширяемость)

— Доступность компетентных ресурсов в организации в нужный момент времени

Выбор технологий — ответственное решение, которое будет дорого стоить организации. Для того чтобы принять правильное решение, настоятельно рекомендуется проводить встречи и стараться принимать его коллективным путем (это в равной степени относится к архитектуре приложения).

Смена технологий в существующем продукте может быть связана с утратой компетенций или исходного кода. Смена архитектуры более частое явление, так как стоимость этой операции меньше, и она завязана на частых инициирующих событиях (архитектурной ошибке, несоответствии архитектуры текущим потребностям и т. д.).

Принятые архитектурные решения необходимо реализовать в продукте. Контроль корректности реализации архитектуры продукта — одна из важнейших функций тимлида. Процесс контроля встраивается в процесс ревью